1. IAM Standards and Specifications for Organizations
The following IAM standards and specifications will help
organizations implement effective and efficient user access management
practices and processes in the cloud. These sections are ordered by four
major challenges in user and access management faced by cloud
users:
How can I avoid duplication of identity, attributes, and
credentials and provide a single sign-on user experience for my
users? SAML.
How can I automatically provision user accounts with cloud
services and automate the process of provisoning and deprovisioning?
SPML.
How can I provision user accounts with appropriate privileges
and manage entitlements for my users? XACML.
How can I authorize cloud service X to access my data in cloud
service Y without disclosing credentials? OAuth.
1.1. Security Assertion Markup Language (SAML)
SAML is the most mature, detailed, and widely adopted specifications
family for browser-based federated sign-on for cloud users. Once the
user authenticates to the identity service, she can freely access
provisioned cloud services that fall within the trusted domain,
thereby sidestepping the cloud-specific sign-on process. Since SAML
enables delegation (SSO), by using risk-based authentication policies
customers can elect to employ strong authentication (multifactor
authentication) for certain cloud services. This can be easily
achieved by using the organization’s IdP, which supports strong
authentication and delegated authentication. By employing strong
authentication techniques such as dual-factor authentication, users
are less vulnerable to phishing attacks that have been growing
steadily on the Internet. Strong authentication to cloud services is also advisable to protect user
credentials from man-in-the-middle attacks—i.e., when computers or
browsers fall victim to trojans and botnet attacks. By supporting a
SAML standard that enables a delegated authentication model for cloud
customers, the CSP can delegate the authentication policies to the
customer organization. In short, SAML helps CSPs to become agnostic to
customer authentication requirements.
Figure 1 illustrates
an SSO into Google Apps from the browser. The figure illustrates the
following steps involved in the SSO process of a user who is federated
to Google:
The user from your organization attempts to reach a hosted
Google application, such as Gmail, Start Pages, or another Google
service.
Google generates a SAML authentication request. The SAML
request is encoded and embedded into the URL for your
organization’s IdP supporting the SSO service. The Relay State
parameter containing the encoded URL of the Google application
that the user is trying to reach is also embedded in the SSO URL.
This Relay State parameter is meant to be an opaque identifier
that is passed back without any modification or inspection.
Google sends a redirect to the user’s browser. The redirect
URL includes the encoded SAML authentication request that should
be submitted to your organization’s IdP service.
Your IdP decodes the SAML request and extracts the URL for
both Google’s Assertion Consumer Service (ACS) and the user’s destination URL (the Relay State
parameter). Your IdP then authenticates the user. Your IdP could
authenticate the user by either asking for valid login credentials
or checking for valid session cookies.
Your IdP generates a SAML response that contains the
authenticated user’s username. In accordance with the SAML 2.0
specification, this response is digitally signed with the
partner’s public and private DSA/RSA keys.
Your IdP encodes the SAML response and the Relay State
parameter and returns that information to the user’s browser. Your
IdP provides a mechanism so that the browser can forward that
information to Google’s ACS. For example, your IdP could embed the
SAML response and destination URL in a form and provide a button
that the user can click to submit the form to Google. Your IdP
could also include JavaScript on the page that automatically
submits the form to Google.
Google’s ACS verifies the SAML response using your IdP’s
public key. If the response is successfully verified, ACS
redirects the user to the destination URL.
The user has been redirected to the destination URL and is
logged in to Google Apps.
1.2. Service Provisioning Markup Language (SPML)
SPML is an XML-based framework being developed by OASIS for
exchanging user, resource, and service provisioning information among
cooperating organizations. SPML is an emerging standard that can help
organizations automate provisioning of user identities for cloud
services (e.g., an application or service running at a customer site
requesting Salesforce.com for new accounts). When SPML is available,
organizations should use it to provision user accounts and profiles
with the cloud service. If SPML is supported, software-as-a-service
(SaaS) providers can enable “just-in-time provisioning” to
create accounts for new users in real time (as opposed to
preregistering users). In that model, the CSP extracts attributes from
the SAML token of a new user, creates an SPML message on the fly, and
hands the request to a provisioning service which in turn adds the
user identity to the cloud user database.
Adoption of SPML can lead to standardization and automation of
user or system access and entitlement rights to cloud services so that customers
are not locked into proprietary solutions.
Figure 2 illustrates an SPML use case in
which an HR system is requesting a provisioning system in the cloud
with the SPML request. In the figure, HR System of Record (requesting
authority) is an SPML web services client interacting with the SPML
provisioning service provider at the cloud service provider, which is
responsible for provisioning user accounts on the cloud services
(provisioning service target).
1.3. eXensible Access Control Markup Language (XACML)
XACML is an OASIS-ratified, general-purpose, XML-based access
control language for policy management and access decisions. It
provides an XML schema for a general policy language which is used to
protect any kind of resource and make access decisions over these
resources. The XACML standard not only gives the model of the policy
language, but also proposes a processing environment model to manage
the policies and to conclude the access decisions. The XACML context
also specifies the request/response protocol that the application
environment can use to communicate with the decision point. The
response to an access request is also specified using XML.
Most applications (web or otherwise) have a built-in
authorization module that grants or denies access to certain
application functions or resources based on entitlements assigned to the user. In a centrally
managed IAM architecture, application-specific authorization models
(silos) make it difficult to state the access rights of individual
users across all applications. Hence, the goal of XACML is to provide
a standardized language, a method of access control, and policy
enforcement across all applications that implement a common
authorization standard. These authorization decisions are based on
various authorization policies and rules centered on the user role and
job function. In short, XACML allows for unified authorization
policies (i.e., the use of one consistent XACML policy for multiple
services).
Figure 3 illustrates the interaction
among various health care participants with unique roles (authorization privileges) accessing sensitive patient
records stored in a health care application.
The figure illustrates the following steps involved in the XACML
process:
The health care application manages various hospital
associates (the physician, registered nurse, nurses’ aide, and
health care supervisor) accessing various elements of the patient
record. This application relies on the policy enforcement point
(PEP) and forwards the request to the PEP.
The PEP is actually the interface of the application
environment. It receives the access requests and evaluates them
with the help of the policy decision point (PDP). It then permits
or denies access to the resource (the health care record).
The PEP then sends the request to the PDP. The PDP is the
main decision point for access requests. It collects all the
necessary information from available information sources and
concludes with a decision on what access to grant. The PDP should
be located in a trusted network with strong access control
policies, e.g., in a corporate trusted network protected by a
corporate firewall.
After evaluation, the PDP sends the XACML response to the
PEP.
The PEP fulfills the obligations by enforcing the PDP’s
authorization decision.
The interaction takes place using a request-response protocol
with the XACML message as the payload. In this way, XACML is used to
convey the evaluation of policies against access decision
requests.